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Title: System and Method for Establishing and Retrieving Data Based on Global Indices 



Field of the invention 

This invention relates generally to storage to data and retrieval of records. More 
particularly this invention relates to a universal method for generating an index of medical 
records at the time services are rendered and retrieving medical records based upon the 
automated indexing performed. 
Background of the invention 

Medical records can reside in many different places. As a patient sees different 
doctors and is treated for different conditions, individual records relating to the patient are 
created in each individual location. Therefore a medical record could exist at a general 
practitioner where the patient goes for annual physicals. At another time a medical record 
could be created for the patient at an immediate care facility where emergency room services 
are rendered. In a similar fashion a medical record for the same patient could be created at a 
particular specialist's office who treats the patient for a particular condition. All of these 
medical records may be critical to the treatment of the patient in any particular circumstance. 
If the total medical record for individual patient is not available, certain diagnoses may be 
overlooked or erroneously made. 

Several systems have addressed the issue of how to create universal medical records. 
In general these systems create medical records by the creation of a file in some central 
storage area. Thereafter the central storage area may be accessed by individual practitioners 
by accessing the central storage of the medical record. Such systems use a "root registration" 
system wherein medical records and identities are registered centrally. Such systems 
generally are not fully automated leading to the potential for errors. Further only "registered" 
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1 records are available to remote users. Thus if a patient's medical record is not centrally 

2 registered, it is simply not available to the practitioner. 

3 Another disadvantage of the central registration process is that, at the present time, no 

4 single format is universal. Thus many different medical organizations have different formats 

5 which cannot be accessed among different medical institutions. Even if such access is 

6 granted, format translation programs must be used which could cause additional errors in 

7 translation. 

8 One example of a system which attempts to obtain a master index of patient 

9 identification information is the telemed system in use at Los Alamos labs. That system 

10 maintains a master index of patient ID's thus tracking patient ID as a master reference. The 

1 1 master ID is then used to determine where to find data related to a particular patient. 

12 Telemed system deals with topological information normally characterizing patient records. 

1 3 Further, the system relies upon "middleware" to resolve differences between database systems 

14 that possess a particular patient's record. Thus a translation mechanism is necessary. 

1 5 Further, the telemed system still requires a master patient index as a form of central 

16 registration. 

17 In contrast to the systems noted above, the present invention does not rely on a root 

1 8 registration or a central registration of client information. Rather, the present invention 

19 establishes an identity for a patient at the time of service, based on the identity of a given 

20 device. This identity is established at the location of the device and not at any central 

21 location. This identity is designated, however, in a universal fashion such that, for patient's 

22 whose identity is established by the system, information relating to that particular patient can 

23 be looked up in a convenient manner. Further, the present invention comprises the data 

24 transfer protocol to allow for global addressing and retrieval of information from sites remote 

-2- 
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1 from the location at which the patient is present. In this matter, all information concerning a 

2 particular patient maybe retrieved by the location treating the patient. 

3 Brief description of the invention 

4 It is therefore and objective of the present invention to be able to locate information 

5 by searching for indices of that information rather than for the information itself. 

6 It is a further objective of the present invention to establish device driven unique 

7 identifiers that identify a person using the system. 

8 It is a further objective of the present invention to establish device driven unique 

9 identifiers that identify a objects that are the subject of transactions using the system. 

10 It is yet another objective of the present information to establish a global identifier for 

1 1 a user of the present invention the first time that a user uses the present invention. 

12 It is yet another objective of the present information to establish a persistent identifier 

13 for a user of the present invention the first time that a user uses the present invention. 

14 It is a further objective of the present invention to uniquely identify a particular device 

1 5 connected to the system. 

16 It is yet another objective of the present invention to establish device identification the 

1 7 first time that a device is activated on the system. 

18 It is a further objective of the present invention to make data universally available as 

1 9 soon as that data is created on the system. 

20 It is another objective of the present invention to make data available at sites remote 

21 from the location at which the data is created as soon as the data is created. 

22 It is yet another objective of the present invention to be able to search for data of 

23 interest without knowledge of the format in which the data was originally created. 

24 It is a further objective of the present invention to allow local sites where data is 

-3- 
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1 created to establish their own formatting and storage policies without such formatting and 

2 storage polices being dictated by a central facility. 

3 It is yet another objective of the present invention to establish security for a users 

4 records by separating the user records from the identification card issues to a user. 

5 The present invention uses a device-based paradigm to avoid the confusion and 

6 restrictions associated with root registration systems. For example, a particular manufacturer 

7 would register its company for participation with the present invention. Identification 

8 numbers are assigned by the manufacturer and used to designate the equipment in question. 

9 Thus equipment from a particular manufacturer which is used by a particular practitioner or 

1 0 health care provider has a unique ID. A date/time stamp is also added to this equipment ID to 

1 1 designate the source and when the equipment is used. 

12 The present invention also comprises a simple network transport up protocol, defined 

13 in this application as the Simple Data Transfer Protocol or SDTP. The SDTP provides 

14 Internet wide sharing of data and database systems through a client/server, transaction based 

1 5 model of data interaction and management. The SDTP allows for the transmission, reception, 

1 6 and recovery of data from disparate locations. 

17 The present invention also provides a network delivery mechanism for addressing 

18 where to find requested information. This subsystem known as the distributed data name 

19 service or DDN S is the reference system by which SDTP operates. This is not meant 

20 however as a limitation. Once the location of information is established by the DDNS, 

21 retrieval of information could occur equally as well by any protocol once that protocol knows 

22 the location of the desired information. 

23 Various universal encoding systems are also used in the present invention so that 

24 individual devices and users of those devices can be encoded in a universal fashion. 

-4- 



WO 00/03526 PCT/US99/14553 - 

1 It should be noted that the preferred embodiment illustrated in this specification is that 

2 of a medical device and data retrieval system. However, the present invention should not be 

3 construed as being so limited. For example the architectures and topology of the present 

4 invention is equally well suited to commercial transactions such as point of sale transactions, 

5 the generation of ATM cards and other commercial ventures. It can also be sued as a form of 

6 identification for employees of large organizations where security and access to facilities in 

7 disparate locations must be tightly controlled. Thus while the medical application will be 

8 elucidated below, those skilled in the art will appreciate that the system and method described 

9 can be applied in many disparate situations. 

1 0 Using the present invention, device manufacturers register their own unique names 

1 1 with the system. For example Hewlett-Packard may register the name "HP" to be used with 

12 all of its device ID numbers whereas another manufacturer such as Phillips might register 

13 another different name "PH." When a medical device is first used on the system, its own 

14 identification (manufacturer, and device ID number) is automatically registered with the 

15 system. A patient receives an ID number, the first time the patient receives an ECG or is x- 

1 6 rayed by equipment that is registered with the system of the present invention. Thus the first 

1 7 time a patient is examined via medical equipment of the present invention, a universal record 

1 8 of not only the equipment, but also the patient is automatically created. 

1 9 The present invention also comprises a user identification token or barcode label 

20 placed on any card of any variety which may be in the form of a credit card, smart card or 

21 other token card which is generated at the time of the first use of any device registered with 

22 the system. From that point on, the patient identification card is "registered" within the 

23 system. Further, the health care provider simply uses the imaging equipment available based 

24 upon the patient identification card, the universal encoding of the system, and images 
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recorded with appropriate patient identification information and image information. In 
addition, the image created is universally available immediately after creation. 

After recording information, the present invention tracks indices to locations of 
information. If the location of the device changes, that information could be tracked by the 
DDNS level 1 server so that queries could be automatically rerouted to the location at which 
the device is currently housed. Thus the information can change as necessary while the index 
to access that information does not. The present invention also does not require standardized 
formatting of information. Thus, local sites format and store their own information as they 
desire without having to adhere to a particular dictated format. Thus local sites do not have 
equipment, staffing, administration, and other matters imposed upon them. 

The system of the present invention transports, sends, delivers, receives, and 
processes information objects. No middleware is required. Transmission of request for 
information and the receiving of that information is done, using the simplified data transfer 
protocol. In addition, existing systems can be included within the present invention since any 
kind of document or object can fit within the present invention as an object. Only 
namespaces as addresses are necessary for the present invention in order to find the location 
of desired information and retrieve that information. 

In summary, the present invention is a device driven addressing system rather than a 
top-down addressing system. Individual devices create the namespace address necessary to 
retrieve information created by the individual device. Thus the present invention allows the 
minimal set of possible information at the top-level, which is used for routing requests for 
information, with actual information created by individual devices or sites stored and located 
at those devices or sites. 

The present invention comprises a Simple Data Transport Protocol (SDTP), 
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Distributed Data Name Service (DDNS) software implementation, and a paradigm for 

automated indexing of global databases. 

The DDNS design is similar in function to the domain name service which supports 
all Internet addresses. The domain name service for the Internet allows a single address to be 
used by any user regardless of that user's location to find another user on the Internet. In a 
similar fashion the DDNS of the present invention supports such a lookup service. However 
DDNS is generalized and optimized for resolving database locations and database service 
locations. 

The DDNS exists in a series of servers in a tree structure whereby medical diagnostic 
equipment are connected to servers. These lower level servers are in turn connected to higher 
level servers in a tree structure or parent-child relationship. There is no practical limit to the 
level of servers in the tree structure. It is only required that there be sufficient levies of 
servers to satisfy the query needs of the organizations connected to the DDNS network. 

Using the DDNS of the present invention, if a client machine requires information it 
does not have, it sends a query to a parent server concerning where to find the record 
information. In this application, the parent server is referred to as a DDNS Level 2 server or 
DDNS-2 server. This situation can exist in the medical sense if a patient, having a medical 
ID card of the present invention, visits an emergency room in other than the patient's home 
city. In that situation the patient may use the patient ID card which will not be recognized by 
the local medical diagnostic equipment. In that case the medical diagnostic equipment will 
query the next higher server regarding where to find information on the patient. 

If the server being queried has the necessary information, and answers the requesting 
client, the Interaction stops. If the server does not have the information, it in turn, asks its 
parent server, and so on up a tree structure of parent-child DDNS servers until the requested 
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information is found. Once the patient index information is found, it is passed back down to 

the originating client which receives address/index information for a direct site to site request. 

At this point a peer-to-peer connection can be made whereby the client receives the desired 

medical information directly from the medical diagnostic equipment or database possessing 

that information. 

The Simplified Data Transport Protocol (SDTP) 

Once the source of the desired information is located it becomes necessary to transfer 
the desired information from one location to another. The Simplified Data Transport 
Protocol (SDTP) of the present invention has this task. SDTP provides Internet- wide 
sharing of data and database systems through a client-server, transaction-based model of data 
interaction and management. SDTP structures transmission, reception, and recovery of data. 
Brief Desc ription of the Figures 
Figure 1 illustrates the DDNS server nodes 
Figure 2 illustrates a DDNS network topology 

Figure 3 illustrates a specific example of an instance of use of the DDNS network topology 
Detailed Description of the Preferred Embodiment 

As noted earlier, the present invention comprises a Distributed Domain Name Service 
(DDNS) software implementation whereby devices and users are uniquely identified and 
registered on servers of the system the first time the devices are used and the first time that 
users use the devices, a Simple Data Transport Protocol (SDTP) whereby once data of 
interest is located, that data can be transported from location to location with ease, and a 
paradigm for automated indexing of global databases. 
Distributed Data Name Service (DDNS) 

Distributed Data Name Service (DDNS) provides a name lookup service for the 
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1 indexing of global databases. It is designed to work in between a transfer protocol such as 

2 SDTP, and an encoding scheme for naming objects uniquely. 

3 The DDNS implementation is similar to DNS (Domain Name Service), which 

4 supports all Internet name lookup service. The basic idea is illustrated in Figure 1 DDNS 

5 Nodal Indexing. 

6 In DDNS , if a client machine needs information it does not have, it asks a parent 

7 server where to find that information. If that server has the information, it answers the 

8 requesting client and the interaction stops. If the server does not have the information, it in 

9 turn asks its parent server, and so on, up a tree structure of parent-child DDNS machines, 

1 0 until the requested information is found. Once the information is found, it is passed back 

1 1 down to the originating client, which receives forwarding information for a direct site-tosite 

1 2 request, at which point a peer-to-peer connection is made "horizontally" in the tree structure. 

13 h is important to note that, strictly speaking, DDNS is not "Middleware". Although it 

1 4 can appropriately interact with Middleware as necessary. 

1 5 DDNS provides efficient recovery of records from anywhere on a network, and has no 

1 6 machine-type or operating system restrictions whatsoever. Its architecture provides intrinsic 

1 7 scalability suitable for supporting universal databases that may require diskspace exceeding 

1 8 current technologies for individual sites. Since it resolves namespaces rather than IP 

1 9 addresses, DDNS will seamlessly migrate to new network protocols such as "IP2" whenever 

20 traditional IP is replaced. Using namespaces also supports organizational durability, since 

2 1 organizations may change names and have these reticulated through the DDNS structure, or 

22 keep the same names and change the undergoing machine hardware supporting those names 

23 without impact of data accessibility to the network. 

24 Tne SDTP/DDNS combination provides an automatic, low-level addressing and 

-9- 
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retrieval mechanism on which other functionality can be conveniently built. Such 

functionality may include automatic invoicing, automatically generated statistical polling of 

part quality, demographic information for illnesses without access to patient identity, etc. 

Such functionality supports electronic interaction and electronic commerce. 

Used with SDTP and other naming and classification conventions, DDNS can provide 

global indexing of any kind of image, produced on any kind of image-producing device, 

making any image retrievable by a click of a barcode reader. Yet images may be produced 

different machines in different countries. Implications of such design specifically include 

SDTP/DDNS/ASIA support for universal image recall through standard medical cards given 

to patients at local hospitals. This is discussed specifically elsewhere in the document. 

Used with other encoding schemes, SDTP/DDNS functionality may conveniently extend 

into diverse applications. Such applications may include automated part tracking, automated 

consumer purchase and repurchase, automated manufacturer-retailer profit distribution, and 

automated assessments of production quality on a plant-by-plant basis. 

The major advantages supporting DDNS design include: 

1 . Machine interactions are name lookups, not actual data transfers, until the very 
last moment when a site-to-site connection can be made. Thus, interactions 
are very fast between machines. 

2. formation contained on any machine emphasizes minimalist storage. A 
machine attempts to keep only the most minimal information it needs on its 
local system, knowing that it can retrieve remote information very quickly 
whenever needed. 

3. Storage of data is genuine distributed. Since DDNS servers only hold index 
information for where to get information, rather than the information itself, 

-10- 
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global databases can be unlimited in size. Even very large global databases 

that exceed the physical storage possibilities of single sites will have excellent 
performance. 

To illustrate the benefits, consider an example in which local sites cannot usefully 
store more than 50 terabytes of information. Since a global database supported by 
SDTP/DDNS only stores addressing information, it can provide information on many such 
sites, letting those sites resolve the actual data internally. 

4 . Each machine may cache its previous lookups and thus avoiding vertical 
lookups for recurrently used data. For data that sister sites will share over and 
over, the caching mechanism allows site-to-site connections without making 
parent-node queries. Thus, performance is very fast, even when scaling to 
very large addressing mechanisms. 

5. Local policies determine disk storage and internal data structure for local 
systems. Yet local information will be available globally. 

Flexibility & Ease of Use 

Flexibility, generality, and ubiquitous accessibility are core principles of the 
SDTP/DDNS implementation. With a minimal "backbone" infrastructure of a small 
collection of machines, DDNS can support numerous concurrent universal databases, 
conveniently supporting as diverse systems as automated parts tracking in automobile repairs, 
insurance records, and purchase and repurchase of any scanable item: clothing, home 
appliances, wood, paint, groceries, etc. Such applications will only require a barcode click on 
behalf of the user. And then on behalf of that user, a computer queries a DDNS server for 
data location, and then SDTP retrieves the data from the appropriate site. 
Simple Data Transport Protocol (SDTP) 
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1 The following terminology and associated definitions are used in this specification: 

2 Database: A collection of records. SDTP supported databases can be local and/or 

3 global. 

4 Record: A denotatum stored in a database. 

5 Transaction: An interaction between a client query and server response. Example 

6 transactions include modifying a global database and finding a record 

7 in a database. 

8 Client Query: A request from a client sent to a server. 

9 Server Response: A response from a server sent to a client. 

1 0 Message: Generally, a client query or server response. Specifically, a content 

1 1 identifier and data object. 

12 Content Identifier: The first string of a SDTP message that identifies SDTP/0.9 

1 3 version, command, and arguments to process. 

14 Data Object: A header and body. Data objects may include text, images, video, 

1 5 sound, etc. 

1 6 Header: Header information in a data object, employing MIME conventions. 

1 7 Bod y : Bod y information in a data object, employing MIME conventions. 

1 8 The Simple Data Transport Protocol (SDTP) of the present invention is a protocol that 

1 9 applies to dynamically distributed, Internet- wide, database systems. 

20 The SDTP protocol provides universal addressing of database systems, and universal 

21 search and retrieval of data stored on such systems. SDTP supports any encoding 

22 mechanism, but is optimized for large scale or universal encoding mechanisms for universal 

23 image tracking. 

24 SDTP distributed database functionality can seamlessly traverse any network 

-12- 
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1 topology, machine-type, operating system, database system, etc. The protocol supports all 

2 forms of data: text, image, video, sound, etc. 

3 SDTP permits intelligent, efficient, fully automated data-sharing on a site-to-site, 

4 device-by-device basis, searching and retrieving specific data sets. Data sets can be located 

5 anywhere on a network, and have no physical storage-size restrictions. Searching can be 

6 local or global. For example, data produced by an ECG machine in Chicago is available to 

7 another ECG machine in Bangkok. 

8 In SDTP data arc no longer viewed as existing on a single system, or any collection of 

9 explicitly linked systems or sub-systems, such as credit card authorization systems. Rather, 

10 SDTP views data as query relations, in which a single, very simple query mechanism 

1 1 dynamically organizes and retrieves germane information at a moment of request. 

12 The basic mechanism works such that when a client query is fully satisfied locally, a 

1 3 search can halt. When a client query is not satisfied locally, within a couple of network 

14 "hops" a SDTP server response will return a comprehensive list of data locations to the 

1 5 requesting client. A given client needs no initial knowledge that related data even exist, or 

1 6 where or how such data are stored. Yet for any given record, a client query can rapidly find 

17 all related records across the Internet-even if related records exist on databases unknown to 

18 exist by the requesting client, at the moment of its request. 

1 9 SDTP can support machine clusters, LANs, WANs, heterogeneous networks, 

20 collections of linked networks, or any set of these. This design explicitly includes support for 

21 full, Internet-wide search and retrieval of records. Essentially, there are no network 

22 restrictions for SDTP; it can transport and retrieve information for local or global systems 

23 alike. 

24 SDTP operations rely on client-server transactions. A transaction is characterized by 

-13- 
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a client sending a message to a server, and the server sending back a message to the client. 

SDTP/0.9 supports two basic transactions, Lookup and Modify, each of which has two 

commands. Table 2 summarizes these relations. 

Lookup index Retrieve a record's index, but not the record itself 

query Retrieve a record. 

Modify ADD Add a record to a database. 

DELETE Remove a record from a database. 

Table 2: Transactions 

Since SDTP applies to any kind of database, existing anywhere on the Internet, SDTP 
transactions provide genuinely global searching, retrieving, adding, and removing records 
from universal databases. 

As noted earlier, a message is a client query or a server response. The data structure 
of messages consists in a content identifier and data object. Table 3 summarizes these 
relations. A content identifier identifies SDTP version, command, and any arguments. A 
data object 

Content Identifier | 

i 

Data Object j Header 

! Body 

Table 3: Message Data Structure 
consists in a header and body, both of which support MIME conventions. A header contains 
information about the transaction-type and data specifications. A body contains data, which 
can include MIME multipart documents, among other data. 

SDTP relies on uniform interaction between clients and servers, transacted through 
client query and server response messages. A client query requests actions from a server. A 
server response answers client queries, and sometimes also performs actions on behalf of the 



-14- 



1 

2 



7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 

21 

22 

23 

24 

25 
26 
27 
28 
29 
30 

31 

32 

33 



WO 00/03526 PCT/US99/14553 
client called server actions. Both client queries and server responses rely on the data structure 

of messages. 

Table 4 summarizes protocol relations. Since transactions are interactions between 
client queries and server responses, a 'Lookup index' transaction would involve an exchange 
between a client query and a server response. In turn, client queries and server responses are 
subject to content identifiers and data objects. 



Transactions 

Client Query 
Server Response 



Lookup 
Modify 

Content Identifier 
Data Object 

Content Identifier 
Data Object 



ADD 



index 
query 

DELETE 

Header 
Body 

Header 
Body 



Table 4: Protocol Relations 

Message Data Structure 

A message is a content identifier and a data object. The SDTP client query content 
identifier syntax is: 

SDTP/version command argument ... 

These expansions describe content identifier semantics: 

version SDTP version number. 
command Keyword specifying SDTP activity. 
argument Argument for command. 

Subsequent arguments. 

Example. Consider this legal content identifier: 

SDTP/0.9 LOOKUP Medlmages 123.abc 
Following the content identifier syntax, the command is 'LOOKUP' with two 
arguments: (l)'Medlmages' (the database to search) and (2) '123.abc' (a record or set of 
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1 records as might occur in a hospital system). 

2 A data object includes (1) a header and (2) a body. A data object may include text, 

3 images, video, sound, any other media or data type, and any combination thereof. 

4 A header consists in one or more lines and is terminated by a blank line. The syntax 

5 for such lines is: 

6 fieldname: data 

7 The argument data may have any number of additional arguments separated by 

8 semicolons (V). These expansions describe the header semantics: 

9 fieldname Label for data field (e.g., Date, Content-Length,Content-Type, etc.) 

10 data Data (e.g., for content-type, cookies etc.) 
11 

12 Client query data object headers additionally can contain preferences for server responses, but 

1 3 SDTP/0.9 does not yet specify these. 

1 4 For example, consider the following data object header. This example illustrates a 

1 5 Lookup transaction that retrieves a record: 

J 6 Content-Type: application/sdtp; transaction -'lookup- 1 "; lookuptype -'query*' 

1 8 A b °dy consists in a MIME body, including multipart bodies [FB96a], This structure 

1 9 facilitates transmission of all data types such as text, graphics, sound, video, etc. 

20 A body contains content or is null. The exact format of the body depends upon 

21 specific databases, and thus is fixed in a separate standardization process not subject to 

22 SDTP. 

23 For example, consider the following data object body. This example indicates a 

24 successful deletion of record ' 1 23.abc': 

25 SUCCEEDED DELETE 123.abc 

26 A client query is a message, and consists in (1) a content identifier and (2) a data 
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1 object. 

2 An example of a client query data object is: 

3 Content-Type: application/sdtp; transaction="modification" 

4 From: medical.cenon.com 
5 

6 DELETE 123.abc 

7 ADD DEF0456 
8 

9 A server response is a message, and consists in (1) always a data object, and (2) 

10 sometimes an additional server action (e.g., a record deletion). See also Message Data 

1 1 Structure. 

12 Unlike client queries, SDTP server responses have no content identifier. Server 

1 3 responses are data objects. 

1 4 Server response data object headers are transaction types. 

1 5 For example, consider the following server response data object header. The 

1 6 Transaction type illustrates address forwarding. 

1 7 Content-Type: application/sdtp; transaction= "forwarding" 

1 8 1116 Server response data object body syntax is determined in the data object header 

1 9 according to the transaction specification. A body contains content or is null. For example, 

20 consider the following server response data object body which illustrates successful deletion 

21 of record '123. abc', and failed addition of record 'DEF@456'. 

22 SUCCEEDED DELETE 123.abc 

23 FAILED ADD DF.F0456 
24 

25 Example Server Response Data Object 

26 Consider this example of a server response data object, including both header and 

27 body: 

28 Content-Type: application/sdtp; transaction- 'modification" 

29 From: medical.cenon.com 
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1 SUCCEEDED DELETE 123,abc 

2 FAILED ADD DEF@456 
3 

4 A server response may invoke a server action, such as adding or deleting a record 

5 from a database. SDTP specifies the structure and syntax of data objects. SDTP specifies a 

6 semantics associated with the server action, but not structure or detail of implementation. 

7 Such considerations axe left to decisions of site-by-site implementation. 

8 Transactions 

9 A transaction consists of (1) a client query (to server), and (2) a server response (to 

10 client). The current version, SDTP 0.9, provides two types of transactions, Lookup and 

1 1 Modify. Table 5 illustrates these relations. 

12 Client Query Server Response 

1 3 Lookup Client queries server Server returns records, 

14 for records. or location instructions for where to find 

15 records. 

16 Modify Client requests server Server synchronizes data 

17 synchronization storage. 
18 

19 Table 5: Transaction Summary 

20 

21 Lookup: A Lookup transaction determines if a node has knowledge of requested 

22 record(s). 

23 Client Query: A Lookup client query is a message, and thus contains (1) a content identifier 

24 and (2) a data object. 

25 (1 ) Content Identifier: An sample Lookup content identifieris as follows: 

26 SDTP/0.9 MODIFY Medlmages 123.abc 

27 (2) Data Object: A Modify data object will contain (A) a header and (B) a body. 

28 (2A) Header: The Lookup header uses a Content-Type that specifies (1) a Lookup transaction 

29 and (2) a lookuptype. A Lookup data object header has syntax: 

30 Content-type: application/sdtp; transaction-'lookup"; lookuptype="type" 'type 'in 
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1 'lookuptype' has these values and meanings in SDTP/0.9: 

2 Value Meaning 

3 query Transfer a record 

4 index Transfer a record's index, but not the record itself 
5 

6 The following example of a Content-Type data object header retrieves a record's 

7 index, but not the record itself: 

8 Content-Type: application/sdtp; transaction="lookup"; lookuptype=-"index M 

9 (2B) Body: A Lookup client query data object body is empty in SDTP/0.9. 

10 Server Response: A Lookup response (1) has no content identifier, and (2) has a data 

1 1 object. 

12 (1) Content Identifier: The Lookup server response has no content identifier. 

13 (2) Data Object: The Lookup server response data object has (A) a header and (B) a body. 

14 (2 A) Header: This header specifies the Content-Type of the server response, but may also 

15 include other information such as MD5 encrypted signatures, etc. 

16 (2B) Body: The body follows MIME message body conventions [FB96a]. SDTP data object 

1 7 bodies have three forms: 

18 1 . One or more records, structured as MIME multipart documents [FB96a]. 

1 9 2. Forwarding instructions, for one or more records, structured as the MIME type 

20 application/sdtp with attribute transaction set to forwarding. For example: 

21 Content-Type: application/sdtp; transaction-'forwarding" 

22 A following data object body would contain a list of addresses to query for records. 

23 3. Compound responses, structured as MIME multipart documents. Each part of a multipart 

24 document will be: 

25 (a) Form 1 , One or more recbrds 

26 (b) Form 2, Forwarding instructions 
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1 (c) Form 3, Compound responses. 

2 Example Lookup Transaction: This example illustrates a Lookup transaction, in which 

3 record *123.abc' is retrieved from universal database 'Medlmages'. The transaction consists in 

4 a client query and a server response. 

5 Client Query: The following 3 line transcript is a plausible client query Lookup record 

6 retrieval request, from medical, cenon.com. 

7 SDTP/0.9 LOOKUP Medlmages 123.abc 

8 Content-Type: application/sdtp; transaction-'lookup"; lookuptype- 'query" 

9 From: medical.cenon.com 
10 

1 1 This query requests the retrieval of record '123.abc' from universal database 

12 'Medlmages'. 

13 Server Response: The following 7 line server response indicates a plausible server reply to 

1 4 the previous client query. 

1 5 % SDTP/0.9 LOOKUP Medlmages 

16 Content-Type: application/sdtp; transaction-' forwarding" 

17 From: medical.cenon.com 
18 

19 ddns-2.uch.net 

20 ddns-2.mag.net 

21 ddns-2.nyc.net 
22 

23 The server forwards the client addresses where questions are answered about record 

24 '123.abc' in universal database 'Medlmages'. 

25 Modify: A Modify transaction synchronizes databases. A client query asks for modification of 

26 server-stored data, such as adding or deleting a record. 

27 Client Query: A Modify client query includes (1) a content identifier and (2)a data object. 

28 (1) Content Identifier 

29 See Content Identifier about content identifier syntax and semantics. An example Modify 

30 content identifier looks like: 
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1 SDTP/0.9 MODIFY Medlmages 1 23 .abc 

2 (2) Data Object 

3 See Data Object about data object syntax and semantics. A Modify data object will contain (A) 

4 a header and (B) a body. 

5 (2A) Header. A Modify data object header specifies a Content-Type using 

6 transaction== ,r modification M . An example looks like: 

7 Content-Type: application/sdtp: transaction- 'modification" 

8 (2B)Body. TheModifydataobjectbodycontainsinstructionsdetailingmodification of the database, 

9 such as adding and deleting records. An example data object body request for deleting record 

10 '123.abc' and adding record 'DEF@456' could be: 

11 DELETE 123 .abc 

12 ADD DEF@456 
13 

14 Server Response 
15 

1 6 A Modify server response (1) has no content identifier, and (2) has a data object. 

17 (1 ) Content Identifier The Modify server response has no content identifier. 

18 (2) Data Object 

19 See Data Object about data object syntax and semantics. The Lookup server response 
.20 data object has (A) a header and (B) a body. 

21 (2 A) Header. This header specifies the Content-Type of the server response, but may also 

22 include other information such as MD5 encrypted signatures, etc. 

23 (2B) Body. The body follows MIME message body conventions [FB96a]. The Modify data 

24 object body may also contain verification information, such as the success or failure of arequest. 

25 Verification information often is null. 

26 Example Modify Transaction 
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1 The following example illustrates a Modify transaction. This example modifies the 

2 universal Medlmages database, where the client query requests to delete record 123.abc and to 

3 add record DEF@456. The transaction consists in a client query and a server response. 

4 Client Query. The following 6 line transcript requests to delete and add a record from 

5 database Medlmages. 

6 SDTP/0.9 MODIFY Medlmages 

7 Content-Type: application/sdtp; transaction="modification" 

8 From: medical.cenon.com 
9 

10 DELETE 123.abc 

11 ADD DEF@456 
12 

13 Line 1 . Client query identifies protocol and requests modification of database Medlmages. 

14 Line 2. 'Content-Type'identifies a SDTP application; 'transaction' specifies a "modification" 

15 transaction type. 

1 6 Line 3 . 'From' identifies client making request. 

1 7 Line 4. Blank line identifies separation between data object header and data object body. 

1 8 Line 5. 'DELETE' removes forwarding for Lookup query of record '123.abc\ 

19 Line 6. 'ADD' enables forwarding to 'medical.cenon.com', for Lookup query of record 

20 'DEF@456'. 

21 Server Response. The following 6 line server response indicates a plausible reply to the previous 

22 client query. 

23 SDTP/0.9 MODIFY Medlmages 

24 Content-Type: application/sdtp; transaction="modification" 

25 From: medical.cenon.com 
26 

27 SUCCEEDED DELETE 123.abc 

28 FAILED ADD DEF@456 
29 

30 Line 1 . Server response identifies protocol and acknowledges request for modification 

3 1 of database Medlmages . 
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1 Line 2. 'Content-Type' identifies a SDTP application; 'trisection 1 specifies a 

2 "modification" transaction type. 

3 Line 3. 'From' identifies client making request. 

4 Line 4. Blank line identifies separation between data object header and data object body. 

5 Line 5 . 'SUCCEEDED' indicates that client query 'DELETE' was completed successfully. 

6 Line 6. 'FAILED' indicates that client query 'ADD' was not completed successfully. 

7 Referring to figure 1 a simplified DDNS Nodal indexing system is illustrated. If the 

8 electrocardiogram analyzer 10 has unique identifier which, for purposes of this illustration is 

9 noted as the number one. When a user first is established with the system of the present 

10 invention the user might be subject to electrocardiogram analyzer testing on, for example, 

1 1 January 1 1th 1998. This date, in combination with unique electrocardiogram analyzer identifier 

1 2 "one" is then registered was in DDNS server 1 4 and. In this example the DDNS server is noted 

13 as a Level-2 server located at the University of Chicago noted with the abbreviation "UCH." 

14 Other electrocardiogram analyzers 12, 16, and 18 are also shown as part of the system. 

1 5 Electrocardiogram analyzer 12 is connected to DDNS server 1 4. Electrocardiogram analyzer 1 6 

1 6 is connected to DDNS server 20 which, in the present example is noted as being associated with 

1 7 Massachusetts general hospital, abbreviated as "MAG.". Electrocardiogram analyzer 1 8 having 

1 8 the unique identifier "4" is connected to DDNS server 22 in New York City. 

19 DDNS level 2 servers 22, 20, and 14 are connected to a DDNS LeveM server 24. The 

20 purpose of the DDNS Level- 1 server 24 is to receive and store a record of the identifiers of of 

2 1 individual date or records created by the individual electrocardiogram analyzers shown in figure 

22 1. It is important to note that the DDNS Level- 1 server 24 does not contain the ultimate 

23 information, that is, the results of electrocardiograms that have been administered to the 

24 particular patient at the various hospitals. (It should be noted that DDNS level 1 server may 
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1 actually be serval machines as is later illustrated.) DDNS Level- 1 server 24 only contains a 

2 record of the indices that show where the information is stored. Thus for example, if a patient 

3 receives an electrocardiogram on January 1 1th 1998 from electrocardiogram analyzer can the 

4 information record concerning that analysis is stored and the user is given a medical 

5 identification card possessing and ID number associated with at first examination. If that patient 

6 is subsequently examined using electrocardiogram analyzer 18 on September 23rd 1998, the 

7 practitioner would obtain the medical identification card of the patient, record that information 

8 through electrocardiogram analyzer 1 8 which would then the determine if it had ever seen that 

9 particular patient before. If not, a query would proceed from electrocardiogram analyzer 1 8 to 

10 DDNS Level-2 server 22 to inquire if a record of that patient exists. If no such record exists at 

1 1 DDNS Level-2 server 22 that server will send a query to DDNS Level- 1 server 24 to determine 

12 if it has a record of the particular patient. 

13 DDNS Level- 1 server or 24 will have such are record of the existence of the particular 

14 patient is existing at electrocardiogram analyzer 1 0 which can be reached via DDNS server 14. 

15 Thereafter DDNS Level-2 22 will make contact with DDNS Level-2 server 14 on behalf of 

16 electrocardiogram analyzer 18, with electrocardiogram analyzer 10. 

17 In this example, DDNS servers of two different levels are shown. The level 2 servers 

18 store and broker requests for indices relating to medical equipment that is connected to them. 

19 The level 1 DDNS servers store and broker requests for indices relating to patients from Level 

20 2 servers connected to them. Thus information is not generally passed when a query is made, 

21 only the identification of the location of the data is transferred. It should also be noted that this 

22 example of use in the medical arena is not meant to be limiting. As will be explained later, other 

23 application areas are equally considered to be within the scope of the present invention. 

24 Referring to figure 2 the network topology of the present invention is illustrated. As 
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1 noted earlier, the present invention is device driven rather than driven by a top-down 

2 classification schemata. A series of medical devices may be attached to a workstation at a 

3 particular hospital. For sample, ECG 4, CT 6, and ECG 12 may all be attached to a workstation 

4 2 at a location, for example, the University of Chisago (UCH). ECG 4 will have its own unique 

5 identifier generally assigned by the manufacturer. When the ECG 4 is first activated to perform 

6 its first examination and creates the appropriate patient record, ECH 4 becomes registered on the 

7 system of the present invention. Thus the global identifier for ECG 4 is created the first time the 

8 device is activated. In a similar fashion, CT 6 also has a unique identifier as does ECG 12. 

9 These devices are also shown as attached to workstation 2. 

1 0 Alternatively medical devices may be self-contained and amenable to being attached or 

1 1 directly connected to a DDNS server. The situation is also illustrated in figure 2 where CT 8 is 

12 shown as directly connected to second level DDNS 14. Additionally, ECG 10 is also shown as 

1 3 connected to the DDNS level 2 server 14. 

14 All of the above devices ECG 4, CT 6, ECG 12, CT 8, ECG 10, and workstation 2 are 

1 5 all uniquely identified and registered with the system of the present invention the moment that 

1 6 they are first activated. As will be shown later, a date time stamp is also used in conjunction with 

1 7 the unique identifier to create a unique patient identifier the first time that the patient uses any 

1 8 device that is registered on the system. 

1 9 In a similar fashion, other medical devices and other geographically disparate locations 

20 can also become registered on the system of the present invention. Again referring to Figure 2 

2 1 ECG devices 1 3 . 1 5, and 1 6 may all be resident at, for example, Massachusetts General Hospital 

22 (in this figure designated as MAG). Additionally, MRI 11 and CT are also shown as located in 

23 Massachusetts General hospital ECG 15 and 16 may be located in emergency room 21 while 

24 ECG 13 may be located in and the attached to a workstation and cardiology 19. MRI 11 and CT 
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1 9 may be connected to workstation 1 7 in radiology. Workstations 21 in the emergency room, 19 

2 in cardiology, and 17 in radiology are all connected to DDNS level 2 server 20. It is important 

3 to note that unique identifiers will only be associated with the devices actually performing the 

4 diagnostic task, that is, devices 9,11, 13,15, and 16. Workstations 17, 19, and 21 will not to have 

5 unique identifiers since they will not be creating the medical records to be searched: It is of 

6 course possible that an individual hospaital may wish to have unique identifiers regarding all 

7 devices on a network whether diagnostic or not in order to be able trace all instances of data or 

8 information created. The present invention will support this implementation as well. 

9 In Figure 2 yet a third location, hypothetical^ a hospital in New York City 

10 (designated as NYC) is shown as having a series of medical devices as well. In this is an 

1 1 instance ECG 18 is connected to a PC 32. That PC is in turn connected to a display 30 was 

12 capable of displaying the results of the ECG analysis. Similarly, ECG 34 is directly 

1 3 connected to display 30. Display 30 is connected to a workstation 26 which has an MRI 

14 device 28 connected to it. This workstation 26 is in turn attached to DDNS level-2 server 22. 

15 All of the DDNS level-2 servers 14,20, and 22 are connected to DDNS level- 1 servers 

16 23, 24, and 25. These DDNS level- 1 servers broker queries for information and client index 

1 7 locations coming from the various geographic locations were a patient may be treated. 

18 It is important to note that once a medical device is activated for the first time, its unique 

19 ID is stored at both the DDNS level-2 server and a DDNS level- 1 server. This is because the 

20 DDNS Level-2 server knows about diagnostic devices connected to it and DDNS Level- 1 servers 

21 know about DDNS Level-2 connected to them. Thus the DDNS servers learn about the 

22 diagnostic devices in different ways. Further, once a patient is treated for the first time using 

23 any medical device that is attached to the present system, a permanent designation for that patient 

24 is created which comprises the unique identifier of the medical device combined with the date 
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1 time stamp of the first treatment of the patient. 

2 In practice, and as will be discussed in detail later, a patient who is treated at ECG 18 in 

3 NYC, and who possesses a medical ID card or barcode label on any card created by the system 

4 will cause a query to be created to determine if any other medical records exist for the patient 

5 Initially a query will go as high as DDNS level-2 server 22. If an index to that client's records 

6 exists within the New York City location, that information will be sent to the operator of ECG 

7 18. If such information does not exist, DDNS level-2 server 22 will add a new record to its 

8 database and will send the query to DDNS level- 1 servers 23, 24, and 25 to determine where a 

9 patient index for that particular patient does exist. If DDNS Level -1 server knows about the 

1 0 record, it will make a record associating the the new data record with the data record that already 

1 1 exists in its database. If the patient was first treated at University of Chicago, the patient index, 

1 2 derived from the medical ID card, will cause a query to be sent to DDNS level -2 server 1 4 which 

13 will respond with the various indices which indicate that location of records relating to the 

1 4 patient of interest. 

15 Examples 

16 By way of example and to further illustrate a preferred embodiment of the present 

17 invention, Figure 3 is presented. Since only data regarding indices to information os being 

1 8 searched, the system of the present invention responds very quickly to queries for the location 

19 of patient information. In the examples that follow, only the date@device designation is used. 

20 In the full implementation the manufacturers ID would also be present as part of the unique 

21 identifier. 

22 1 . Jane comes the University of Chicago Hospital on 1 1 December 1 998 for the first time, 

23 to receive her first ECG ever, where she receives a University of Chicago Hospital medical card 

24 as a normal part of her admission. Upon receiving an EGG exam, Jane' s reading is automatically 
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1 entered into the University of Chicago Hospital's local database system, and a printer produces 

2 a small sticker which a nurse affixed to Jane's medical card. 

3 SDTP/0.9 MODIFY Medlmages 

4 Content-Type; application/sdtp; transaction="modification" 

5 From; ddns-2.uch.net 
6 

7 ADD 1998121 1@1 
8 

9 Since DDDS-2 :UCH has never seen record ' 1 998 1 2 1 1 @ 1 \ it attempts to 'ADD' it to the 

10 next level "up" (to DDNS-1 Servers). A similar SDTP client query is sent "up" to DDNS-1 

1 1 Servers. 

1 2 2. DDNS- 1 Servers receive and process the following client query request to ADD record 

13 4 1 998 1 2 1 1 @l'to the global 'Medlmages' database: 

14 SDTP/0.9 MODIFY Medlmages 

15 Content-Type; application/sdtp; transaction- modification" 

16 From: ddns-2.uch.edu 
17 

18 ADD 1998121 1@1 
19 

20 Since DDNS-1 Servers have not yet seen record '1998121 1@1' DDNS-1 Servers store 

21 it. Using the From: field, DDNS-1 Serviers further associate ' 1998121 1@1 ' with address 'ddns- 

22 2.uch.edu.' DDNS-1 ServerswillnowforwardfutureLookuprequestsforrecord'1998121 1@1' 

23 to DDNS-2-.UCH. 

24 DDNS-1 Servers return a SDTP server response to DDNS-2:UCH. The response 

25 indicates successful completion of the request ADD for ' 1 998 1 2 1 1 @1 1 in database 'Medlmages. ' 

26 The server response is: 

27 SDTP/0.9 MODIFY Medlmages 

28 Content-Type: application/sdtp; transaction- 'modification" 

29 From: ddns-2 uch.edu 

30 SUCCEEDED ADD 1998121 1@1 
31 

32 The DDNS system has now globally registered record ' 1 998 1 2 1 1 @ 1 ' in the universal database 
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1 'Medlmages'. 

2 Crucial implications follow from this design 

3 (a) A local system creates a global identifier in a flilly automatic manner, without any human 

4 intervention whatsoever. 

5 (b) This process requires no form of "root registration" for users of equipment. 

6 (c) A user may operate whatever local system is most desirable, without interference from 

7 SDTP/DDNS. 

8 3. Jane returns for a follow-up visit on 22 Dec 1998. A nurse clicks a barcode reader on 

9 Jane's medical card, which concurrently prompts DDNS-2:UCH to do an internal Lookup* client 
] 0 query for the number encoded onto her card ('1 998 1 2 1 1 @ 1') which was encoded during her first 

1 1 visit on 1 1 Dec 1998. Since DDNS-2:UCH has the record '1 998121 1 @V it stops searching, and 

12 does not query DDNS-1 Servers. Jane's previous reading of 11 Dec 1998 is automatically 

13 recalled onto the screen. 

14 4. The 'ADD' command now saves the 22 Dec 1 998 reading, associating it with the 1 1 Dec 1 998 

1 5 reading through the global index (database "key") ' 1 998 1 2 1 1 @ 1 '. The SDTP interaction looks 

16 like: 

17 SDTP/0.9 MODIFY Medlmages 

18 Convent-Type: application/sdtp; transaction="modification" 

19 From: ddns-2.uch.edu 
20 

21 ADD 1998121 1@1 

22 

23 The attending physician refers Jane to a Networked Specialist Physician, who makes an 

24 appointment of 5 Jan 1 999. 

25 Crucial implications follow from the client-server interactions up to now: 

26 (a) DDNS-1 Servers store a mapping from record '19981 21 1@1' to DDNS-2:UCH. DDNS- 

27 2UCH has a mapping to whatever internal mechanism the University of Chicago Hospital uses 
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1 to record its data. 

2 (b) DDNS- 1 Servers and DDNS-2 :UCH only know about one record ('1998121 1@1 ')>while 

3 the University of Chicago Hospital knows about two records. A "one-to-many" relationship is 

4 created. 

5 Because only 1 number is stored at the DDNS- 1 Servers level, global system performance 

6 is optimized. Only 1 number provides potential access to all of Jane's records at the University 

7 of Chicago Hospital. 

8 (c) Routine business at the University of Chicago Hospital remains on site. This reduces 

9 system complexity on the local side, and further optimizes Level- 1 DDNS performance. DDNS 

10 uses global resources only when local resources do not have the needed information. 

11 (d) A user participates in global information sharing without any special interaction besides 

1 2 barcode reading a medical card. Currently, optical readers provide the most robust construction, 

13 but any other encoding mechanism could be used. Similarly, rather than affixing a label, the 

14 medical card be given at the end of the visit, with the universal identifier indelibly marked on the 

1 5 card. 

16 5. On 5 Jan 1999 Jane arrives for her referral appointment with a Networked Specialist 

17 Physician (NSP) made during her last visit to the University of Chicago Hospital on 22 Dec 

18 1998. 

19 A nurse at the NSP barcode-reads Jane's University of Chicago Hospital medical card 

20 to begin the process. The NSP local machine does an internal client query 'Lookup' for the 

21 number encoded onto Jane's card )'19981211@1'). This record is not found on the local 

22 machine, and so the machine sends a client query to DDNS-2:UCH. 

23 SDTP/0.9 LOOKUP Medlmages 1998121 1@1 

24 6. DDNS-2.UCH receives the previous client query and does an internal 'Lookup' for 
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1 4 1998121 1@1', which it finds. Since the search for record 4 1998121 1 @V is satisfied, DDNS- 

2 2:UCH does not query DDNS- 1 Servers. DDNS-2:UCH returns records from 1 1 Dec 1 998 and 

3 22 Dec 1998. 

4 Although miles from the University of Chicago Hospital, clicking a barcode reader on 

5 Jane's medical card provides the NSP instant retrieval of previous ECG readings at the 

6 University of Chicago. 

7 7, Although appearing to the SNP in the same moment, the system now ADDs the reading 

8 taken on 5 Jan 1 999 to the NSP local syste, associating it with the global index 4 1 998 1 2 1 1 @ 1 '. 

9 Since record ' 1 998 1 2 1 1 @ 1 ' is stored for the first time on the NSP local machine, the NSP 

10 local machine also attempts to ADD "up" record '1998121 \@\\ for global registration in 

1 1 databas 'Medlmages'. The NSP local system sends this command to it DDNS server, DDNS- 

12 2 ,, UCH: 

1 3 SDTP/0.9 MODIFY Medlmages 

14 Convent-Type: application/sdtp; transaction="modification M 

15 From: specialist.uch.edu 
16 

17 ADD 1998121 l@l 
18 

19 8. DDNS-2:UCH receives the previous client query 4 ADD\ Since DDNS-2:UCH has 

20 already registered record ' 1998121 1@1', it now associates the NSP address with record 

21 * 1998121 as an address answering questions about global record ' 1998 121 1@1\ DDNS- 

22 2:UCH returns a server response indicating the successful status of the client query ADD: 

23 SDTP/0.9 MODIFY Medlmages 

24 Convent-Type: application/sdtp; transaction-'modification" 

25 From: specialist.uch.edu 
26 

27 ADD 1998121 1@1 
28 

29 9. On 6 Jun 1999 Jane visits Massachusetts General Hospital (MAG). A nurse barcode 

30 reads Jane's University of Chicago medical card, which posts an internal Lookup client query to 
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1 DDNS-2:MAG, for the original ECG taken on 11 Dec 1998 (in Chicago, affixed to Jane's 

2 University of Chicago Hospital card). 

3 Not having seen record 1 1 99812 1 1@1 ■ before, DDNS-2:MAG asks if DDNS-1 Servers 

4 hnow where to find information about this record. DDNS-2:MAG sends this client query 

5 Lookup request to DDNS-1 Servers: 

6 SDTP/0.9 LOOKUP Medlmages 1998121 1@1 

7 10. DDNS-1 Servers receive DDNS-2:MaG's previous client query Lookup for record 

8 '1998121 \@V in global database 'Medlmages 5 . DDNS-1 Servers do know about record 

9 '1998121 1@1': that DDNS-2:UCH answers questions about it. 

10 11. DDNS- 1 Servers send a server response indicating that DDNS-2:UCH answers queries 

1 1 about record '1998121 \@V. The forwarding message sent is: 

1 2 SDTP/0.9 LOOKUP Medlmages 

1 3 Content-Type : application/sdtp; transact ion- 1 forwarding" 
14 

15 ddns-2.uch.edu 
16 

17 12. DDNS-2:MAG directly connects to DDNS-2:UCH. which queries machine 

1 8 specialist.uch.edu, requesting records related to '1 998121 1@1 ': 

19 SDTP/0.9 LOOKUP Medlmages 19981211@1 

' 20 DDNS-2:UCH returns records for ECG readings taken on 5 Jan 1 999, 22 Dec 1 998, and 

21 11 Dec 1998. 

22 Barcode reading Jane's University of Chicago Hospital medical card in Massachusetts 

23 General Hospital instantly retrieves Jane's previous records, displaying the images on the screen 

24 within a moment of clicking the barcode reader. 

25 13. Although appearing in the same moment from the nurse's point of view, the system now 

26 saves the 6 Jun 1999 reading to the local Massachusetts General Hospital machine. 
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1 Since DDNS-2:MAG does not have the '11 Dec 1998* reading (globally indexed by 

2 ' 1 998 12 1 1@1 '), it adds '1998121 to its database, associating it with the new reading taken 

3 locally on 6 Jun 1999. Since '1998121 1@1' is a new record to DDNS-2:MAG, it also attempts 

4 to ADD "up" the record just scanned from Jane's University of Chicago Hospital medical card, 

5 '1998121 DDNS -2: MAG sends a client query ADD to DDNS-1 Servers. 

6 SDTP/0.9 MODIFY Medlmges 

7 Content-Type: application/sdtp; transaction="modification" 

8 From: ddns-2.mag.org 
9 

10 ADD 1998121 1@] 

11 

12 14. DDNS- 1 Servers receive the previous client query request to ADD record 1 1 998 1 2 1 1 @ V 

13 to global database 'Medlmages'. Since DDNS-1 Servers already know about record 

14 '1998121 1@1', DDNS-1 Servers store the address in the From: header (ddns-2.mag.org) as a 

15 location that will answer queries for global record '1998121 1@1\ 

16 Future Lookup requests for record '1 998121 \@V now will receive forwarding 

17 instructions for both DDNS -2 :M AG and DDNS-2:UCH. DDNS-1 Servers now sends a server 

1 8 response indicating status of the request: 

1 9 SDTP/0.9 MODIFY Medlmages 

20 Content-Type: application/sdtp; transaction-'modification" 

21 From: ddns-2.mag.org 
22 

23 SUCCEEDED ADD 1 998 1 2 1 1 @1 

24 

25 15. Jane is in a car accident in New York City, and is rushed to a random hospital, where an 

26 attendant discovers a University of Chicago Hospital medical card in her purse. 

27 Clicking a barcode reader on the card, a DDNS-2 :N YC internal Lookup learns that record 

28 '1998121 l@r is unknown. So it sends a client query Lookup request "up", to DDNS-1 Servers. 

29 16. DDNS-L Servers receive a client query Lookup request from DDNS-2:NYC: 

30 SDTP/0.9 LOOKUP Medlmages 1998121 1@1 
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1 DDNS-1 Servers know about record '1998121 and have two forwarding address 

2 associations: DDNS-2:MAG and DDNS-2:UCH. 

3 17. DDNS- 1 Servers know that DDNS-2:UCH and DDNS-2:M AG answer queries forrecord 

4 '1 998 121 1 and return forwarding instructions for these addresses. 

5 SDTP/0.9 LOOKUP Medlmages 

6 Content-Type: application/sdtp; transaction- 'forwarding" 
7 

8 ddns-2.mag.org 

9 ddns-2.uch.edu 
10 

11 18. DDNS-2:NYC directly connects to DDNS-2:MAG and DDNS-2:UCH, querying for 

12 record '1998121 using the following client query for both addresses: , 

13 SDTP/0.9 LOOKUP Medlmages 1998121 1@1 

14 Four records appear on the screen in the emergency room: 

15 6Junl999 DDNS-2:MAG 

16 5 Jan 1999 DDNS-2:UCH 

17 22 Dec 1998 DDNS-2:UCH 

18 11 Dec 1998 DDNS-2:UCH 
19 

20 While the top-level DDNS service (DDNS-1 Servers) only knows about global record 

21 '1998121 1@1', the New York Hospital emergency room now views four records, from three 

22 devices, from two different sites, simply by barcode reading a University of Chicago Hospital 

23 medical card. 

24 The physicians need not know from which facilities Jane has records, and yet her 

25 comprehensive ECG records are available instantaneously. 

26 1 9. Although appearing to the emergency room in the same moment, the system now ADDs 

27 the reading taken on 23 Sep 1999 to the local DDNS-2:NYC system, associating it with the 

28 global index of '1998121 1@1\ 

29 Since record '1998121 1@1' is stored for the first time on the DDNS-2:NYC, DDNS- 
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1 2:NYC also attempts to ADD "up" record '1998121 for global registration in database 

2 'Medlmages'. 

3 20. DDNS-1 Servers receives the following client query request to ADD record 

4 '1998121 1@1' to global database 'Medlmages', from DDNS-2:NYC. 

5 SDTP/0.9 MODIFY Medlmages 

6 Content-Type: application/sdtp; transaction-'modification" 

7 From: ddns-2.nyc.com 
8 

9 

10 ADD 19981211@1 

11 

12 Since DDNS-1 Servers already know about record '1 9981 21 1@P (from DDNS-2:MAG 

1 3 and DDNS-2:UCH), DDNS-1 Servers add the address in the From: header (ddns-2. nyc.com) to 

14 the list of addresses that will answer queries for global record '1998121 1@1\ DDNS-1 Servers 

1 5 then sends a server response indicating status of DDNS-2:NYC's client query ADD request: 

1 6 SDTP/0.9 MODIFY Medlmages 

1 7 Content-Type: application/sdtp; transaction-'modification" 

18 From: ddns-2.nyc.com 
19 

20 SUCCEEDED ADD 1 998121 1@1 

21 

22 Having made this addition, DDNS-1 Servers will answer future Lookup requests for 

23 record '199812 1 1@1' with forwarding instructions to: 

24 DDNS-2:NYC 

25 DDNS-2:MAG 

26 DDNS-2:UCH. 
27 

28 21. While on vacation in the Florida Keys, away from convenient access to a hospital, Jane 

29 experiences chest pain. She goes to an Independent Practitioner (IP) on 8 Oct 1 999, and presents 

30 her University of Chicago Hospital medical card, which the physician barcode reads. 

31 The physician's local machine does an internal client query 'Lookup 1 for the number 

32 encoded onto Jane's University of Chicago card (' 1 998 1 2 1 1 @ 1 '). This record is not found on the 
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1 local machine, and so the local machine sends a client query to DDNS-2:1SP. 

2 SDTP/0.9 LOOKUP Medlmages 1998121 1@1 

3 22. DDNS-2:ISP receives theprevious client query Lookup request for record'l 998 121 l@V 

4 in global database 'Medlmages'. Not having seen record ' 1998 1 2 1 1 @1* before, DDNS-2:ISP 

5 asks if DDNS-1 Servers know where to find information about record '1998121 1@1'. DDNS- 

6 2:ISP sends this client query Lookup request to DDNS-1 Servers: 

7 SDTP/0.9 LOOKUP Medlmages 1998121 1@1 

8 23. DDNS-1 Servers receive DDNS-2:ISP's previous client query Lookup for record 

9 *19981211@r in global database 'Medlmages'. DDNS-1 Servers know that these addresses 

10 answer questions about record '1998121 1@1': 

1 1 DDNS-2:NYC 

12 DDNS-2:MAG 

13 DDNS-2:UCH. 
14 

15 24. DDNS-1 Servers send a server response indicating forwarding addresses that answer 

16 queries about global record '1998121 1@T. The forwarding message sent is: 

17 SDTP/0.9 LOOKUP Medlmages 

18 Content-Type: application/sdtp; transaction="forwarding" 
19 

20 ddns-2.nyc.com 

21 ddns-2.mag.org 

22 ddns-2.uch.edu 
23 

24 25. DDNS-2:ISP directly connects to DDNS-2:ISP, DDNS-2:MAG, and DDNS2:UCH, 

25 querying for record ' 1 998 1211 01', using the following client query for all addresses: 

26 SDTP/o.9 LOOKUP Medlmages 1998121 1@1 

27 Five records appear on the Local Practitioner's screen: 

28 23 Sep 1999 DDNS-2:NYC 

29 6Junl999 DDNS-2:MAG 

30 5 Jan 1999 DDNS-2:UCH 

31 22 Dec 1998 DDNS-2:UCH 
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1 11 Dec 1998 DDNS-2:UCH 

2 

3 These records represent Jane's cumulative ECG patient history beginning on 1 1 Dec 1998, 

4 globally indexed to record ' 1998 121 l@l'. Thus, even in a remote area, the Independent 

5 Practitioner has instantaneous access to live records, from four devices, from different sites thou- 

6 sands of miles apart, simply by barcode, reading a University of Chicago Hospital medical card. 

7 26. Although appearing approximately in the same moment as the record retrievals, the 

8 system now saves the 8 Oct 1999 reading to the IP's local system. 

9 Since the local system does not have the '11 Dec 1998' reading (globally indexed by 

10 ! 1 998 12 1 1 @r), it adds 1 1 998 1 2 1 1 @1 1 to its database, associating it with the new reading taken 

11 locally on 8 Oct 1999. 

12 Since 4998121 is a new record to the IP's local system, the local system also 

13 attempts to ADD "up" the record ('1998121 l@Y) just read from Jane's University of Chicago 

14 Hospital medical card. The IP's local system sends a client query ADD to DDNS-2:ISP. 

1 5 SDTP/0.9 MODIFY Medlmages 

16 Content-Type: application/sdtp; transaction-'modification" 

17 From: practitioner.isp.com 
18 

19 ADD 19981211@1 

20 

21 27. DDNS-2:ISP receives the previous client query request from the Independent 

22 Practitioner's machine to ADD record '1998121 1@1' to global database 'Medlmages'. 

23 Since DDNS-2:ISP does not know about record '1998121 1@1' it stores it locally, 

24 associating it with the address in the From: header as an address that answers queries for global 

25 record ' 1 998 12 1 1 @V. DDNS-2 :ISP will know in the future to query address practitioner.isp.com 

26 for records related to global record '19981211@r. DDNS-2 :ISP returns a server response 

27 indicating status of the client query from the Independent practitioner machine. 

28 SDTP/o.9 MODIFY Medlmages 
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1 Content-Type: application/sdtp; transaction- 'modification" 

2 From: practitioner.isp.com 
3 

4 SUCCEEDED ADD 1998121 1@1 
5 

6 Since record '1998121 1@1' is new to DDNS-2:ISP, it also passes the client query ADD 

7 "up" to DDNS- 1 Servers. DDNS-2 :ISP sends the following client query ADD request to DDNS- 

8 1 Servers; 

9 SDTP/0.9 MODIFY Medlmages 

10 Content-Type: application/sdtp; transaction- 'modification" 

1 1 From: ddns-2.isp.net 
12 

13 ADD 1998121 1@1 
14 

15 28 . DDNS- 1 Servers receive the previous client query request to ADD record 1 1 998 1 2 1 1 @ 1 ' 

16 to global database 'Medlmages', from ddns-2.isp.net. 

17 Since DDNS-1 Servers already know about record '1998121 1@1' (from DDNS-2 :NYC, 

18 DDNS-2 :MAG and DDNS-2 :UCH), DDNS-1 Servers store the address in the From: header 

19 ('ddns-2. isp. net), associating it with the other addresses that answer queries for global record 

20 '19981211@r. 

2 1 DDNS- 1 Servers return a server response indicating the status of the previous client query 

22 ADD request from DDNS-2:ISP. 

23 SDTP/0.9 MODIFY Medlmages 

24 Content-Type: application/sdtp; transaction- 'modification" 

25 From: ddns-2.isp.net 
26 

27 SUCCEEDED ADD 1 9981211@1 
28 

29 Now future Lookup requests for global record '1998121 1@1' will receive forwarding 

30 instructions for: 

31 DDNS-2:ISP 

32 DDNS-2:NYC 

33 DDNS-2 :M AG 

34 DDNS-2:UCH. 
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1 Of course, each address answers queries using its own network architecture, storage 

2 procedures, and database policies. SDTP/DDNS provides uniform access to the ECGs stored at 

3 these addresses. 

4 This example illustrates the flexibility and generality of DDNS service for large, distributed 

5 collections of data. In this paradigm, data can reside on different machines and machines that 

6 do not know about one another, unlike much traditional design for large database systems. 

7 Databases need not be explicitly linked. 

8 Similarly, in this paradigm, data exists as query relations, dynamically organizing and 

9 relating information at moments of request. Yet record recall is efficient, even across the 

10 Internet, providing approximately instantaneous response time. 

11 For clarity and ease of illustration, this example illustrates a "two-level" hierarchy of 

12 machines. However, SDTP/DDNS databases can be arbitrarily deep rather than two layers deep. 

13 At any moment, new servers can be added at any level in the hierarchy, providing each orga- 

14 nization with maximal opportunity to optimize its own performance, and to administer its own 

15 policies. 

16 The DDNS system is driven by manipulation of names, by design permitting easy 

17 portability of machines within any organization. In this respect a namespace becomes a 

1 8 global variable to which a machine or machines become attached. Thus, for example, ddns- 

1 9 2.nyc.com could be a single machine, or a pointer to other machines; and/or the New York 

20 Hospital could change the type of machine supporting the ddns-2.nyc.com namespace without 

21 interrupting service to its local or global community. 

22 The present invention comprises software on computers and firmware in certain of the 

23 medical diagnostic devices. The devices of the present invention comprise those medical 

24 diagnostic devices known in the art which have the ability to store and output information. 
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1 The DDNS servers of the present invention comprise hardware and software and local storage 

2 for storing information comprising indices relating to uses of devices on the network. Any of 

3 a variety of IBM PC and compatibles are suitable to the task of the workstations attached to 

4 the medical diagnostic equipment or as DDNS-Level-2 servers. All that is required is that 

5 there be sufficient storage to store the indices noted. The DDNS level- 1 servers can also be 

6 IBM PC, Sun workstations or indeed any server capable of storing and retrieving information 

7 and communicating that information via modems or otherwise to other servers or 

8 workstations of the present invention. Thus the software giving rise to the unique identifiers 

9 is stored at the lower levels of the system while software for storing, retrieving and associated 

10 indices are typically located at the high levels servers of the system. 

1 1 Further Examples: 

12 * On a home computer, Jane clicks a barcode on the last grocery receipt, which 

13 reproduces the same order as the week before. Arriving at the grocery store, 

14 the order has been charged to her credit card, and is waiting for pick up. 

15 • On a home computer John clicks a barcode reader on an old pair of athletic 

1 6 shoes. A web page appears on which he is offered a choice to repurchase the 

17 same shoes (same brand, size, color, etc.), from the same company. He 

1 8 mouse-clicks on "Accept" and the same credit card is charged that originally 

19 purchased the shoes. The shoes are delivered to his house the next day. One 

20 barcode click and one mouse click consummate this interaction. 

21 • A student goes to a book store needing several chapters of various books. He 

22 selects a book of interest from the shelves, and using the bookstore's PC 

23 "kiosk", clicks on Chapter 3. A web-page returns instantly, indicating that he 

24 may purchase this chapter for $1.83, for which he may use his credit card or 
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1 pay the cashier. 

2 Unknown to the consumer, at the moment of clicking the barcode reader, the 

3 publisher has been consulted and the publisher's royalties and bookstore's profit margins have 

4 been combined in the $1 .83 purchase. Each month the publisher sends automatically 

5 generated invoices to bookstores that itemize royalties due. Such a mechanism works just as 

6 easily for images in publications, and journal articles, etc., and in libraries and photocopy 

7 shops to enhance copyright protection. 

8 • A car owner brings a car to a garage for a muffler repair. Clicking a barcode 

9 reader, the mechanic learns that the muffler is in warranty. The mechanic 

10 provides better service to the car owner, and receives automatic part 

1 1 restocking from the manufacturer. 

12 The manufacturer not only automatically tracks muffler repairs for a given model, but 

1 3 also the precise plants from which the failed mufflers come. The manufacturer has an 

14 automatic way to track part life-cycles, manufacturing defects, repair warranties, replacement 

15 policies, etc. Yet such data gathering is accomplished in the process of normal automotive 

16 repair. 

1 7 On site, a furnace repairman clicks a barcode reader at a broken furnace part, a 

1 8 cellular phone calls into a local service provider, which in turn recalls the repair history of the 

1 9 furnace, and the part availability for repair. New parts can be ordered from the portable 

20 decoder the repairman brings to on-site jobs. 

2 1 The repair process is streamlined, permitting the repairman to order parts order 

22 directly from the manufacturer, while on-site, through an on-site cellular connection to a local 

23 service provider, by passing administrative overhead back at the home office. 

24 Many other such examples apply, such automatic tracing of insurance records by an 
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insurance company; repurchases of home appliances, wood, paints. The entire process is 

universally and automatically indexed at production or transaction time, supported by this 

document's "device-based" approach to universal database construction. 

A system and method for establishing and retrieving data based on global indices has 

been described. As previously noted, although a medical application has been described, it 

will be appreciated by those skilled in the art from reviewing the specification and the 

examples given that many other embodiments are possible using the system with departing 

from the scope of the invention as disclosed. 
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1 We claim: 

2 1 . A Method for Establishing and Retrieving Data Based on Global Indices comprising: 

3 establishing a unique device ID for each of a plurality of data generating devices on a 

4 network; 

5 registering the unique device ID of each of the plurality of data generating devices on 

6 the network on at least one server connected to the network when the data generating 

7 equipment is first used on the network; 

8 establishing a unique user ID for each user of the data generating devices when the 

9 user uses one of the plurality of data generating devices for the first time; and 

10 retrieving data generated by the plurality of data generating devices by searching for 

1 1 instances of the unique user ID. 

1 2 2. The Method for Establishing and Retrieving Data Based on Global Indices of claim 1 

13 wherein establishing the unique user ID further comprises combining the device ID of 

14 the data generating device being used by the user with a date/time stamp of the first 

15 use by the user. 

16 3. The Method for Establishing and Retrieving Data Based on Global Indices of claim 2 

17 further comprising storing the unique user ID on a token given to the user. 

1 8 4. The Method for Establishing and Retrieving Data Based on Global Indices of claim 3 

19 further comprising the user using the token with the unique user ID for all subsequent 

20 uses of any of the plurality of data generating devices. 

21 5. The Method for Establishing and Retrieving Data Based on Global Indices of claim 1 

22 wherein the data generated is medical data concerning the user. 

23 6. The Method for Establishing and Retrieving Data Based on Global Indices of claim 1 

24 wherein the data generated is commercial data. 
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1 7. A System for Establishing and Retrieving Data Based on Global Indices comprising: 

2 a network; 

3 a plurality of servers connected to the network for storing data and responding to 

4 search requests; 

5 a plurality of data generating devices connected to the servers, wherein each data 

6 generating device has a unique ID that is registered with at least one server when the data 

7 generating device is first used of the network; 

8 unique user ID generator associated with each data generating device whereby a 

9 unique user ID is established by combining the unique device ID with a date time stamp of 

1 0 when the user first used any of the plurality of data generating devices on the network; and 

1 1 search logic for searching for instances of the unique user ID on any of the plurality of 

12 servers. 

1 3 8. The System for Establishing and Retrieving Data Based on Global Indices of claim 7 

14 wherein the data generating devices are medical data generating devices. 

15 9. The System for Establishing and Retrieving Data Based on Global Indices of claim 7 

16 further comprising tokens generated by each of the plurality of data generating devices 

17 on which is stored each unique user ID. 

18 10. The System for Establishing and Retrieving Data Based on Global Indices of claim 7 

1 9 wherein the data generated is commercial data. 

20 11. The System for Establishing and Retrieving Data Based on Global Indices of claim 9 

21 wherein each of the plurality of data generating devices further comprises a token 

22 reader for reading the unique user ID stored on the token of a user. 

23 12. The System for Establishing and Retrieving Data Based on Global Indices of claim 7 

24 further comprising data transport logic for transporting data generated from one data 
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1 generating device to another once the location of the data has been determined by the 

2 search logic identifying instances of the unique user ID on any of the plurality of 

3 servers. 

4 13. A Method for Establishing and Retrieving Data Based on Global Indices comprising: 

5 establishing a unique device ID for each of a plurality of data generating devices on a 

6 network; 

7 registering the unique device ID of each of the plurality of data generating devices on 

8 the network on at least one server connected to the network when the data generating 

9 equipment is first used on the network; 

1 0 establishing a unique record ID for each record of the data generating devices when 

1 1 the record is created using one of the plurality of data generating devices for the first time; 

12 and 

13 retrieving data generated by the plurality of data generating devices by searching for 

14 instances of the unique record ID. 

15 14. The method for establishing and retrieving data based on global indices of claim 1 3 

16 4 wherein the records creating is creating records of parts of an assembly. 
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